Limiting execution of software programs

ABSTRACT

Techniques are disclosed for limiting execution of software programs. For example, a method comprises the following steps. A first set of program code is extracted from a second set of program code. The extracted first set of program code is parsed to generate a parsed structure. The parsed structure generated from the first set of program code is examined for one or more expressions predetermined to be unsafe for execution. The one or more expressions predetermined to be unsafe for execution that are contained in the first set of program code are detected. In one example, the first set of program code may be a script generated with the JavaScript™ scripting language and the second set of program code may be a business process.

CROSS-REFERENCE TO RELATED APPLICATION

This application is a Continuation of U.S. patent application Ser. No.13/036,440, filed on Feb. 28, 2011, the disclosure of which isincorporated herein by reference.

FIELD

The field relates to scripting languages and script execution and, moreparticularly, to limiting execution of software programs which includeundesirable or malicious software code or scripts associated with suchprograms.

BACKGROUND

Many web-based programming environments, such as Hypertext MarkupLanguage (HTML), Business Process Execution Language (BPEL), andBusiness Process Markup Notation 2.0 (BPMN 2.0), provide fields thataccept a set of expressions or script written with a scripting languagesuch as JavaScript™ (Oracle Corporation, Redwood Shores, Calif.) or anexpression language such as XPATH. A “script,” therefore, is a programor sequence of instructions (e.g., software code) that is said to be, orconsidered to be, executed or carried out by another program rather thanby a computer processor (cf., a compiled program).

Those programming environments that allow scripting languages provide apotential for any kind of program to run within their execution(runtime) environment. Unfortunately, this might include undesirable ormalicious programs.

For example, cloud computing environments include shared resources opento subscribers or registered users. Thus, a “cloud” is generally knownto be a shared computing environment. The National Institute ofStandards and Technology (NIST) provides an illustrative definition(version 15 dated October 2009) of “cloud computing” as a model forenabling convenient, on-demand network access to a shared pool ofconfigurable computing resources (e.g., networks, servers, storage,applications, and services) that can be rapidly provisioned and releasedwith minimal management effort or service provider interaction.

It is known that services available for deploying business processes inthe cloud allow users to create and deploy their own programs. Suchprograms are capable of having undesirable or even malicious effects onthe computing environment in which they are executed.

For example, such programs may intentionally or unintentionally containinfinite loops and other logic errors that prevent termination. Usersbilled for the service by usage might have an unpleasant surprise afterdeploying a process that has an infinite loop error. A malicious usercould test the boundaries of system usage with a denial of serviceattack, consuming resources that would otherwise be available forlegitimate users. The combination of business processes and clouddeployment creates risk from both legitimate and malicious users. First,non-technical people may create business processes and may be morelikely than technical professionals to inadvertently inject undesirablebehavior. Second, the runtime environment is accessible to many withmore or less stringent controls.

SUMMARY

Principles of the invention provide techniques for limiting execution ofsoftware programs including unsafe program code.

For example, in one aspect of the invention, a method comprises thefollowing steps. A first set of program code is extracted from a secondset of program code. The extracted first set of program code is parsedto generate a parsed structure. The parsed structure generated from thefirst set of program code is examined for one or more expressionspredetermined to be unsafe for execution. The one or more expressionspredetermined to be unsafe for execution that are contained in the firstset of program code are detected.

The detecting step may further comprise flagging each of the one or moreexpressions predetermined to be unsafe for execution that are containedin the first set of program code.

The method may further comprise displaying the one or more expressionspredetermined to be unsafe for execution that are contained in the firstset of program code.

The method may further comprise preventing execution of the one or moreexpressions predetermined to be unsafe for execution that are containedin the first set of program code.

The method may further comprise preventing execution of the second setof program code when at least one of the one or more expressionspredetermined to be unsafe for execution are detected in the first setof program code.

The parsed structure may comprise a parsed tree structure. The secondset of program code may comprise a business process or a web page. Thefirst set of program code may comprise a segment of code generated usinga scripting language such as, by way of example, JavaScript™.

The one or more expressions predetermined to be unsafe for execution maycomprise one or more of: a function call expression; a functiondefinition expression; a goto expression; a while expression; a forexpression; a property read expression; a property write expression; anda prototype assignment expression.

The second set of program code may be deployable in a shared computingenvironment, e.g., a cloud computing environment.

These and other objects, features, and advantages of the presentinvention will become apparent from the following detailed descriptionof illustrative embodiments thereof, which is to be read in connectionwith the accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates an example of a process which contains one or morescripts that may result in undesirable behavior.

FIG. 2 illustrates an example of a process which contains one or morescripts that may result in malicious behavior.

FIG. 3 illustrates a script development/deployment system which limitsexecution of scripts that may cause undesirable and malicious behavior,according to an embodiment of the invention.

FIG. 4 illustrates a methodology for limiting execution of scripts thatmay result in undesirable and malicious behavior, according to anembodiment of the invention.

FIG. 5 illustrates an example of a set of program code that containsexpressions that may result in undesirable and malicious behavior,according to an embodiment of the invention.

FIG. 6 illustrates an example of a list displayed to a user indicatingexpressions in the program code of FIG. 5 that have been flagged,according to an embodiment of the invention.

DETAILED DESCRIPTION

It to be appreciated that, while illustrative embodiments of theinvention will be described herein in the context of the JavaScript™scripting language, principles of the invention are not limited to thator any particular scripting language. Examples of other scriptingenvironments or languages in which principles of embodiments of theinvention may be implemented include, but are not limited to, Ruby™(Yukihiro Matsumoto), Python™ (Python Software Foundation), PHP™ (PHPGroup), Perl™ (Perl Foundation), Bash™ (Free Software Foundation),XQuery™ (W3C), BPMN™ (Object Management Group), BPEL™ (OASIS), and SQL™(Structured Query Language, ANSI).

Before describing illustrative principles of embodiments of theinvention, we provide a few examples of processes (computer programs)which contain one or more scripts that may result in undesirable and/ormalicious behavior.

FIG. 1 illustrates an example of a process which contains one or morescripts that may result in undesirable behavior. More particularly, FIG.1 shows a BPMN 2.0 diagram 100 representing a sample business process.The sample process is adapted from D. Fahland et al., InstantaneousSoundness Checking of Industrial Business Process Models, BPM '09:Proceedings of the 7th International Conference on Business ProcessManagement, pages 278-293, Springer-Verlag, Berlin, Heidelberg, 2009.

The diamonds with plus marks represent parallel splits and joins. Thediamonds with X marks represent decisions and ‘OR’ joins. On the surfacethe process looks reasonable. A business user might describe the process100 as follows. If everything is acceptable after Activity One, we doActivity Five and finish. Otherwise, we do Activity Two followed byActivity Three and Activity Four in parallel. With Activity Three done,we can do Activity Five, With Activity Four done, if all is okay, we cando Activity Six. If the check after Activity Four fails, we start over.

However, it is realized that the process 100 of FIG. 1 representsundesirable behavior on three fronts: (1) one or more scripts used toimplement the process contain deadlocks; (2) one or more scripts used toimplement the process contain synchronization faults; and (3) one ormore scripts used to implement the process contain a potentiallyinfinite loop.

A soundness check on the process 100 would detect the following errors.First, if the test after Activity One passes immediately, the processwill deadlock waiting for Activity Three. If the test after Activity Onefails immediately, and the test after Activity Four passes, the processwill deadlock waiting for Activity Five. Whenever the decision testafter Activity Four fails, the process creates an “extra” execution ofActivity Three that will be left dangling if the process eventuallycompletes. The process will loop indefinitely, creating infinitedangling executions of Activity Three, when the branches after ActivityOne and Activity Four both always evaluate to ‘No’.

While the flaws in the process 100 may be evident to a computerscientist experienced with Petri Nets, and to a software engineerfamiliar with parallel programming, they may not be readily evident to aweb designer. Furthermore, a business executive thinking in terms of“what needs to be done when” will likely not notice any problems in theprocess 100.

FIG. 2 illustrates an example of a process which contains one or morescripts that may result in malicious behavior. More particularly, FIG. 2demonstrates a process 200 that loops indefinitely while generatingmessages. The messages contain links to sites that install malware tosend more messages that create new process instances. The malwaremessages contain new email addresses. On receipt of the malwaremessages, the process updates the address database and continues toloop. Neither the initial process nor the processes instantiated byincoming messages will terminate. Thus, this script represents a processexplosion as well.

Advantageously, as will be described in detail herein, principles ofembodiments of the invention limit the execution of a scripting languagewithin a hosted environment to expressions considered safe. That is,principles of embodiments of the invention provide methods and systemsthat limit execution of scripts that may cause undesirable and maliciousbehavior, including but not limited to the behaviors described above inthe context of FIGS. 1 and 2. Furthermore, principles of embodiments ofthe invention generate configurations that specify which expressions areconsidered unsafe, and then prevent their execution. Unsafe scriptingexpressions or constructs that may be limited/prevented may include, butare not limited to, ‘function call’, ‘function definition’, ‘goto’,‘while’, ‘for’, ‘property read’, and ‘property write’. Specifically forJavaScript™, the limited/prevented constructs may also include‘prototype assignment’.

As mentioned above, JavaScript™ is one of the languages commonly enabledfor script activities and specifying expressions in business processes.JavaScript™ is far more dangerous than a language such as XPATH becauseJavaScript™ supports looping, ‘function definition’, and ‘functioncall’. JavaScript™ not only has structured loops and recursion aspotential sources for unbounded execution, but also the ‘goto’construct.

In accordance with illustrative embodiments of the invention, a systemand methodology are provided for static checking of programs developedwith JavaScript™ for potential unbounded behavior. This approachcomprises checking for the loop potential constructs in the code andflagging the constructs if they occur. In one embodiment, aconfiguration file is set up that specifies that ‘for’, ‘while’, ‘goto’,and ‘function call’ constructs get flagged on a traversal of a parsetree created for the subject program code. This will be explained ingreater detail below in the context of FIG. 4.

As is well known in terms of computer programming environments,“flagging” typically refers to assigning an indicator to the programcode that represents a status of some part of the program code. A “flag”can be implemented as one or more bits in the code and can be set orunset based on some condition. In one embodiment, a bit associated withthe unsafe constructs gets set to indicate it is identified as aconstruct to be avoided, limited or suppressed, i.e., not executed.

It is further realized that a second source of difficulty withJavaScript™ is function overloading through prototype assignment. Asimple call to a string length function, for example, might causeexecution of anything but string length, if some earlier code assigned adifferent function in the string prototype. Thus, in one embodiment,potential function overloading is flagged by detecting assignment toprototype, and ‘function definition’ is therefore flagged.

Flagging JavaScript™ constructs in this manner, principles ofembodiments of the invention can detect whether JavaScript™ usage in aprocess expression is of the more benign arithmetic evaluation sort, orif it is of the more potentially dangerous program execution sort.Function calls are generally not a problem in expression evaluationprovided they are not infinitely recursive. Function calls combined withprototype assignment, on the other hand, represent a real potentialhazard.

FIG. 3 illustrates a script development/deployment system 300 whichlimits execution of scripts that may cause undesirable and maliciousbehavior, according to an embodiment of the invention. It is to beunderstood that the system 300 is referred to as a scriptdevelopment/deployment system since it can function as a scriptdevelopment system and/or a script deployment system. In deploymentmode, the system (methodology) detects undesirable expressions andprevents execution. In development mode, the system (methodology) helpsan end user identify any expressions that the deployment will reject.Further, in development mode, the resulting flagged expressions might behighlighted in an editor. Still further, in deployment mode, the flaggedexpressions might be logged for audit or review.

The system comprises a processor (i.e., processor device) 302, which iscoupled to memory 304 and interfaces 306. The processor 302 comprises ascript expression detection and flagging module 310 for detecting, in agiven input set of program code (e.g., one or more business processes orweb pages), the presence of a given set of script expressions(constructs) that are considered unsafe (e.g., undesirable and/ormalicious) and thus are to be prevented from being executed. Theprocessor 302 may also comprise a script deployment checker 320 forchecking a version of the input program code set prior to deployment.The modules 310 and 320 may execute under the control of a centralprocessing unit (CPU) 330 of the processor.

The processor 302 obtains: (i) a configuration file which specifieswhich expressions are considered unsafe; and (ii) at least one programto be tested. The processor 302 then processes, via the scriptexpression detection and flagging module 310, the program code based onthe configuration file to generate an unsafe expression-flagged versionof the input set of program code. The flagged version of the code, orintermediate parts thereof, can be displayed to a user of the system 300in order that the user may edit the code to remove the unsafeexpressions. The script expression detection and flagging methodologywill be further illustrated and described below in conjunction with FIG.4. Furthermore, the flagged version of the program code can be providedto the script deployment checker module 320 which rejects processes withflagged expressions, i.e., prevents scripts with unsafe expressions frombeing executed in a program.

The processor 302 and one or more additional components of system 300such as memory 304 and interfaces 306 may be part of a computer, serveror other type of processing device. One or more of the modules 310 and320 in FIG. 3 may be implemented at least in part in the form ofsoftware that is stored in memory 304 and executed by processor 302.

The memory 304 is an example of what is more generally referred toherein as a computer program product having embodied therein executableprogram code, and may comprise electronic memory such as RAM or ROM,magnetic memory, disk-based memory, optical memory or other types ofstorage elements, in any combination. The processor 302 may comprise oneor more microprocessors, microcontrollers, application-specificintegrated circuits (ASICs), field programmable gate arrays (FPGAs),graphical processing units (GPUs) or other processing devices, in anycombination, for executing program code stored in memory 304. As notedabove, the modules 310 and 320 may be implemented at least in part inthe form of such program code.

The interfaces 306 may comprise, for example, user interfaces such asdisplays, keyboards and other input-output devices, as well as networkinterfaces for interfacing processor 302 with other system elements overone or more networks.

It is to be appreciated that the particular arrangement of the scriptdevelopment/deployment system 300 as shown in FIG. 3 is presented by wayof illustrative example only. Alternative embodiments may include otherarrangements of system elements suitably configured to support limitingexecution of scripts that may result in unsafe (undesirable and/ormalicious) behavior in the manner described herein.

The processor 302 and its associated memory 304 or portions thereof maybe implemented at least in part in the form of an integrated circuit.For example, in a given implementation the processor 302 may be embodiedin a single ASIC or other type of processing device, such as, forexample, an FPGA, GPU, computer, server, mobile communication device,etc.

FIG. 4 illustrates a methodology 400 for limiting execution of scriptsthat may result in undesirable and malicious behavior, according to anembodiment of the invention. That is, FIG. 4 represents an illustrativemethodology used to detect unwanted expressions within one or moreprograms (e.g., business processes or web pages).

The methodology starts at block 410. In step 420, the methodology readsa configuration file that contains monitored classes of expressions suchas, for example, those that use looping constructs, function calls, orprototype assignment. That is, as mentioned above, the configurationfile may specify, as unsafe, constructs such as, for example, ‘functioncall’, ‘function definition’, ‘goto’, ‘while’, ‘for’, ‘property read’,and ‘property write’ and ‘prototype assignment’.

In step 430, the methodology extracts the script expressions from thesubject software program being tested. Such software program maycomprise, for example, one or more business processes or one or more webpages. This is a particularly advantageous step since the methodology400 is able to automatically extract script expressions from the mixedcontent that comprises the business process or web page. It is realizedthat software programs that contain script expressions specificallyidentify those expressions as such for evaluation. Thus, the methodology400 may identify script expressions for extraction in the same way thatlanguage runtime interpreters detect them for execution. Step 440 is alooping guard that determines whether there are any scripts remaining tocheck.

In step 450, the methodology converts an individual script or expressioninto a parsed tree. Parsing and parsed tree generation are well-knowntechniques in the field of Computer Science, for example, see Aho,Sethi, Ullman, Compilers: Principles, Techniques, and Tools,Addison-Wesley, 1986, the disclosure of which is incorporated byreference herein in its entirety. The methodology, in step 460,traverses the entire parsed tree and, for each node in the tree, checksin step 470 whether that node constitutes one of the monitored classesof expressions. After visiting all of the scripts (verified by step440), the methodology reports any violations in step 480 and exits atblock 490. Reporting violations may comprise displaying an error messageto a user of the script development/deployment system that shows theuser which expressions have been flagged as unsafe. The user can then goback to the program and delete the unsafe expression and replace it withan alternative that could then be rechecked. Also, a flagged version ofthe program code that is subjected to the methodology 400 can beprovided to the script deployment checker module 320 (FIG. 3) whichrejects any programs with flagged expressions, i.e., prevents scriptswith unsafe expressions from being executed.

By way of example only, FIG. 5 illustrates a set of program code 500that contains expressions that may result in undesirable and/ormalicious behavior, according to an embodiment of the invention. Asillustratively explained above, the set of program code 500 includespotentially dangerous expressions such as JavaScript™ expressions,function call expressions, and prototype assignment expressions, all ofwhich may possibly cause undesirable and/or malicious behavior whenexecuted.

In accordance with the execution of methodology 400 in FIG. 4, FIG. 6illustrates an example of a list 600 displayed to a user indicatingexpressions in the program code 500 of FIG. 5 that have been flagged.That is, the list 600 is an example of a result generated by theexecution of methodology 400 on program code 500. Thus, note that theline number references in list 600 correspond to the line numbers of thesoftware code set 500 in FIG. 5. It is to be appreciated that theexamples given in FIGS. 5 and 6 are for illustration purposes only, andthat simpler or more complex programs may be processed in accordancewith principles of embodiments of the invention.

As will be appreciated by one skilled in the art, embodiments of theinvention may be embodied as a system, method or computer programproduct. Accordingly, embodiments of the invention may take the form ofan entirely hardware embodiment, an entirely software embodiment(including firmware, resident software, micro-code, etc.) or anembodiment combining software and hardware aspects that may allgenerally be referred to herein as a “circuit,” “module” or “system.”Furthermore, embodiments of the invention may take the form of acomputer program product embodied in one or more computer readablemedium(s) having computer readable program code embodied thereon. Agiven computer readable medium of this type may be part of or otherwiseassociated with a processor such as the above-noted ASICs or FPGAs.

Any combination of one or more computer readable medium(s) may beutilized. The computer readable medium may be a computer readable signalmedium or a computer readable storage medium. A computer readablestorage medium may be, for example, but not limited to, an electronic,magnetic, optical, electromagnetic, infrared, or semiconductor system,apparatus, or device, or any suitable combination of the foregoing. Morespecific examples (a non-exhaustive list) of the computer readablestorage medium would include the following: an electrical connectionhaving one or more wires, a portable computer diskette, a hard disk,RAM, ROM, an erasable programmable read-only memory (EPROM or Flashmemory), an optical fiber, a portable compact disc read-only memory(CD-ROM), an optical storage device, a magnetic storage device, or anysuitable combination of the foregoing. In the context of this document,a computer readable storage medium may be any tangible medium that cancontain, or store a program for use by or in connection with aninstruction execution system, apparatus, or device.

A computer readable signal medium may include a propagated data signalwith computer readable program code embodied therein, for example, inbaseband or as part of a carrier wave. Such a propagated signal may takeany of a variety of forms, including, but not limited to,electro-magnetic, optical, or any suitable combination thereof. Acomputer readable signal medium may be any computer readable medium thatis not a computer readable storage medium and that can communicate,propagate, or transport a program for use by or in connection with aninstruction execution system, apparatus, or device.

Program code embodied on a computer readable medium may be transmittedusing any appropriate medium, including but not limited to wireless,wireline, optical fiber cable, RF, etc., or any suitable combination ofthe foregoing.

Computer program code for carrying out operations for embodiments of theinvention may be written in any combination of one or more programminglanguages, including an object oriented programming language such asJava, Smalltalk, C++ or the like and conventional procedural programminglanguages, such as the “C” programming language or similar programminglanguages. The program code may execute entirely on the user's computer,partly on the user's computer, as a stand-alone software package, partlyon the user's computer and partly on a remote computer or entirely onthe remote computer or server. In the latter scenario, the remotecomputer may be connected to the user's computer through any type ofnetwork, including a local area network (LAN) or a wide area network(WAN), or the connection may be made to an external computer (forexample, through the Internet using an Internet Service Provider). Agiven computer or server may comprise one or more processors, such asthe above-noted GPUs.

Embodiments of the invention are described herein with reference toflowchart illustrations and/or block diagrams of methods, apparatus(systems) and computer program products according to embodiments of theinvention. It will be understood that each block of the flowchartillustrations and/or block diagrams, and combinations of blocks in theflowchart illustrations and/or block diagrams, can be implemented bycomputer program instructions. These computer program instructions maybe provided to a processor of a general purpose computer, specialpurpose computer, or other programmable data processing apparatus toproduce a machine, such that the instructions, which execute via theprocessor of the computer or other programmable data processingapparatus, create means for implementing the functions/acts specified inthe flowchart and/or block diagram block or blocks.

These computer program instructions may also be stored in a computerreadable medium that can direct a computer, other programmable dataprocessing apparatus, or other devices to function in a particularmanner, such that the instructions stored in the computer readablemedium produce an article of manufacture including instructions whichimplement the function/act specified in the flowchart and/or blockdiagram block or blocks.

The computer program instructions may also be loaded onto a computer,other programmable data processing apparatus, or other devices to causea series of operational steps to be performed on the computer, otherprogrammable apparatus or other devices to produce a computerimplemented process such that the instructions which execute on thecomputer or other programmable apparatus provide processes forimplementing the functions/acts specified in the flowchart and/or blockdiagram block or blocks.

The flowchart and block diagrams in the figures illustrate thearchitecture, functionality, and operation of possible implementationsof systems, methods and computer program products according to variousembodiments of the invention. In this regard, each block in theflowchart or block diagrams may represent a module, segment, or portionof code, which comprises one or more executable instructions forimplementing the specified logical function(s). It should also be notedthat, in some alternative implementations, the functions noted in theblock may occur out of the order noted in the figures. For example, twoblocks shown in succession may, in fact, be executed substantiallyconcurrently, or the blocks may sometimes be executed in the reverseorder, depending upon the functionality involved. It will also be notedthat each block of the block diagrams and/or flowchart illustration, andcombinations of blocks in the block diagrams and/or flowchartillustration, can be implemented by special purpose hardware-basedsystems that perform the specified functions or acts, or combinations ofspecial purpose hardware and computer instructions.

It should therefore again be emphasized that the various embodimentsdescribed herein are presented by way of illustrative example only, andshould not be construed as limiting the scope of the invention. Forexample, alternative embodiments of the invention can utilize differentscripting languages and script development/deployment systemconfigurations, than those described above in the context of theillustrative embodiments. These and numerous other alternativeembodiments within the scope of the appended claims will be readilyapparent to those skilled in the art.

What is claimed is:
 1. An apparatus comprising: a memory; and aprocessor device operatively coupled to the memory and configured to:generate a configuration file comprising one or more constructspredetermined to be unsafe for execution as identified by a user;extract a first set of program code from a second set of program code;parse the extracted first set of program code to generate a parsedstructure; examine the parsed structure generated from the first set ofprogram code for one or more expressions that use at least one of theone or more constructs predetermined to be unsafe for execution, whereinthe examination further comprises providing a looping guard to verify ifthe entire first set of program code has been examined; detect the oneor more expressions that use at least one of the one or more constructspredetermined to be unsafe for execution that are contained in the firstset of program code, wherein the detecting step further comprisesflagging each of the one or more expressions that use at least one ofthe one or more constructs predetermined to be unsafe for execution thatare contained in the first set of program code; and generate anunsafe-expression flagged version of the first set of program code forediting by a user.
 2. The apparatus of claim 1, wherein the processordevice is further configured to display the one or more expressions thatuse at least one of the one or more constructs predetermined to beunsafe for execution that are contained in the first set of programcode.
 3. The apparatus of claim 1, wherein the processor device isfurther configured to prevent execution of the one or more expressionsthat use at least one of the one or more constructs predetermined to beunsafe for execution that are contained in the first set of program codewhile allowing execution of at least one of: any remaining portion ofthe first program code without the one or more expressions; and thesecond program code, to execute.
 4. The apparatus of claim 1, whereinthe processor device is further configured to prevent execution of thesecond set of program code when at least one of the one or moreexpressions that use at least one of the one or more constructspredetermined to be unsafe for execution are detected in the first setof program code.
 5. The apparatus of claim 1, wherein the parsedstructure comprises a parsed tree structure.
 6. The apparatus of claim1, wherein the second set of program code comprises a business process.7. The apparatus of claim 1, wherein the second set of program codecomprises a web page.
 8. The apparatus of claim 1, wherein the first setof program code comprises a segment of code generated using a scriptinglanguage.
 9. The apparatus of claim 1, wherein the one or moreexpressions that use at least one of the one or more constructspredetermined to be unsafe for execution comprise one or more of: afunction call construct; a function definition construct; a gotoconstruct; a while construct; a for construct; a property readconstruct; a property write construct; and a prototype assignmentconstruct.
 10. The apparatus of claim 1, wherein the second set ofprogram code is deployable in a shared computing environment.
 11. Anarticle of manufacture comprising a non-transitory computer readablestorage medium having tangibly embodied thereon computer readableprogram code which, when executed, causes a processor device to:generate a configuration file comprising one or more constructspredetermined to be unsafe for execution as identified by a user;extract a first set of program code from a second set of program code;parse the extracted first set of program code to generate a parsedstructure; examine the parsed structure generated from the first set ofprogram code for one or more expressions that use at least one of theone or more constructs predetermined to be unsafe for execution, whereinthe examination further comprises providing a looping guard to verify ifthe entire first set of program code has been examined; detect the oneor more expressions that use at least one of the one or more constructspredetermined to be unsafe for execution that are contained in the firstset of program code, wherein the detecting step further comprisesflagging each of the one or more expressions that use at least one ofthe one or more constructs predetermined to be unsafe for execution thatare contained in the first set of program code; and generate anunsafe-expression flagged version of the first set of program code forediting by a user.
 12. The apparatus of claim 1, wherein editing by auser comprises at least one of removing the one or more expressions thatuses at least one of the one or more constructs predetermined to beunsafe for execution and replacing the one or more expressions with oneor more alternative expressions.
 13. The apparatus of claim 5, whereinthe parsed tree structure comprises one or more nodes.
 14. The apparatusof claim 13, wherein the processor device is further configured totraverse the parsed tree structure and check each of the one or morenodes for the one or more expressions predetermined to be unsafe forexecution that are contained in the first set of program code.